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METHOD FOR MANAGING CARD-APPRQVAL-1NFORMATION USING 
MEMORY ADDRESS AND CREDIT-CARD SYSTEM USING THAT 

Technical Field 

5 The present invention relates to a method for managing 

card-approval-information and a credit-card system using the method, 
and more particularly, to a method for managing 
card-approval-information using a management number (for example, an 
Alias number), which is allocated to a card when the card is issued by a 

10 card company, and a credit-card system using the method. 

Background Art 

Recently, a traditional method of collecting transport fares in cash 
or token has been changed into a method of collecting transport fares 
15 using a prepay card or postpay credit card settlement method based on a 
radio frequency (RF) method. 

A transport fare collection method using an RF card makes a 
passenger feel free from a burden of necessity of carrying cash when 
using a public transportation and remarkably reduces a time taken for 
20 collecting a transport fare. In particular, a postpay RF credit card 
removes an inconvenience of a prepay method requiring refilling of an 
amount in advance to use and functions as both a credit card and a 
transport card, and thus is gaining public favor. 

Since a postpay card method is based on a check of black list (BL) 
25 data during a collection or settlement, it is necessary to install a BL data 
storage module at each card terminal and periodically update BL data. 
As an updating period of the BL data becomes shorter, fares or charges 
can be more accurately collected. 

However, when the BL data in the BL data storage module of each 
30 card terminal is updated, it takes a large amount of time to transmit new 
BL data to each card terminal. 
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For example, when 1,000,000 BL cards having poor credit 
information are recorded in a BL database (DB), since a data size of a 
single BL card number is 16 bytes (16 digits where a single digit takes 1 
byte), a total size of the BL DB is 16 Mbytes. Accordingly, it takes about 

5 55 minutes to download BL data from an aggregate computer to a card 
terminal in a conventional automatic fare collection system in which a 
communication line between the aggregate computer and the card 
terminal has a transmission rate of 38,400 bps. This result is obtained 
at an ideal maximum transmission speed. Actually, it takes average 15 

10 minutes to transmit 100,000 bytes, and therefore, it takes about 150 
minutes to transmit the 1 ,000,000-byte BL data. 

When the BL data is directed transmitted from a central computer 
to the card terminal, a transmission rate is 19,200 bps, half of the 
transmission rate between the aggregate computer and the card terminal. 

15 In this case, it takes about 300 minutes to complete a download of the BL 
data. 

Such a transmission time of BL data is considered as being a 
great amount of time in an automatic subway or railway fare collection 
system. Generally, a suspension time of the subway or railway service 
20 is only two or two and a half hours each day. Moreover, in addition to 
the BL data to a card terminal of a gate, the aggregate computer needs 
to process many types of information, such as station information related 
to service times, a discount rate application table, a fare table, and a 
station code table. 

25 When the communication line is occupied during a download of 

the BL data from the aggregate computer to the card terminal, other jobs 
cannot be executed. Resultantly, only a small amount of time is allowed 
for data communication between the aggregate computer and the card 
terminal other than the download of the BL data, and therefore, it is 
30 difficult to manage a subway or railway service system. 
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Moreover, since the BL data has a property of increasing in size 
over time, it is anticipated that a transmission time of the BL data from 
the centra! computer or the aggregate computer to the card terminal 
increases gradually. 

5 In the meantime, recently card companies allocate a management 

number (for example, an Alias number) as well as a card number to a 
card when issuing the card and manage both the management number 
and the card number. Unlike the card number, the management 
number is a serial number. The above-described problems of BL data 

10 transmission can be solved by using the characteristic of the 
management number in the postpay card method. 

Disclosure of the Invention 

The present invention provides a method for managing 
15 card-approval-information using a management number (for example, an 
Alias number) additionally allocated to a card when a card company 
issues the card, and a credit-card system using the method. 

According to an aspect of the present invention, there is provided 
a method for managing card-approval-information. The method 
20 includes dividing a memory area, which has a predetermined size and 
used for storing card-approval-information and user attribute information, 
into a plurality of unit memory sections having a predetermined size and 
allocating a logical address to each of the unit memory section; 
generating and allocating a unique card number to a card, selecting a 
25 logical address of each unit memory section in order, and allocating the 
selected logical address to the card as a management number, while 
initially issuing or reissuing the card; generating a management table for 
managing a relationship between the management number and the card 
number and storing the management number and the card number in a 
30 memory chip of the card; storing card-approval-information and user 
attribute information of the card in a unit memory section corresponding 
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to the management number of the card; and generating a 
card-approval-information download message including a start address 
of the memory area and data stored in the memory area and transmitting 
the card-approval-information download message to terminal 
5 apparatuses and a predetermined system, which require the 
card-approval-information. 

According to another aspect of the present invention, there is 
provided a credit-card system using card-approval-information having a 
memory address. The credit-card system includes a central computer, 
10 which is connected to a server system of a card company through 
Internet and/or a private line, receives poor credit information and 
card-approval-information having a memory address from the server 
system, and stores and manages them in a separate storage place; and 
a card terminal, which receives the poor credit information and the 
15 card-approval-information having the memory address from the central 
computer, stores and manages them in a separate storage place, 
generates radio waves to communicate with a card approaching within a 
predetermined distance therefrom, and determines validity or invalidity of 
the card approaching thereto based on the poor credit information, the 
20 card-approval-information having the memory address, and card 
information obtained via the communication with the card. 

Preferably, the credit-card system further includes a aggregate 
computer, which is connected to the central computer and the card 
terminal through the Internet and/or the private line, receives the poor 
25 credit information and the card-approval-information having the memory 
address from the central computer, stores and manages them in a 
separate storage place, transmits them to the card terminal, and 
transmits a result of processing performed by the card terminal to the 
central computer. 

30 

Brief Description of the Drawings 
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FIG. : is a flowchart of a method for managing 
card-approval-information using a memory address, according to an 
embodiment of the present invention. 

FIGS. 1A throu gh 1F show examples of memory and message 
5 formats used in the method for managing card-approval-information 
using a memory address according to the embodiment of the present 
invention. 

FIG. 2 is a block diagram of a credit-card system according to an 
embodiment of the present invention. 
10 FIG._3Js a block diagram of a card terminal of the credit-card 

system according to the embodiment of the present invention. 

FIGS . 4 through 7 are flowcharts showing an operation of the card 
terminal according to the embodiment of the present invention. 

15 Best mode for carrying out the Invention 

Hereinafter, embodiments of the present invention will be 
described in detail with reference to the attached drawings. 

FIG. 1 is a flowchart of a method for managing 
card-approval-information using a memory address, according to an 

20 embodiment of the present invention. Referring to FIG. 1, a memory 
area, which stores each card's approval information and card user's 
attributes, is divided into unit memory sections having a predetermined 
size, and a logical address is allocated to each unit memory section 
(S110). FIG. 1A is a diagram of a structure of the divided memory area. 

25 A predetermined memory area is set to store card-approval-information, 
and the predetermined memory area is divided into unit memory sections 
having a predetermined size "a", as shown in FIG. 1A. When a start 
number is represented by "A" and a size of each unit memory section is 
represented by "a", an actual address of a "logical address 1" is "A", an 

30 actual address of a "logical address 2" is "A+a", and an actual address of 
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a "logical address 3" is "A+^v9" a -i- . 

^ , _ 3x2 ■ Acc °rtmgly, a logical address and 

actual address are related by Formula (1). 



an 



Actual address of logical address V = A+a(n-1) 



•(1) 



When a card is initially issued or reissued, a unique card number 
generated and allocated to .be card, and a logical address o f a un 

::z7::tt: in order is " as a ma ~< — 

s t ea d ' " 2 S130> ' 1A ' * — 9 -en, number of a 

card ,s 1 , a management number of a second card is "2" and a 
management number of a third card is -y. An aclual address of ^ 
management number can be calculated using Formula (1, 

A management table for managing . relationship 
m na numbef ^ ^ ^ ^ ^ ^ the 

(S140). An exampie of me management table is shown in FIG B 

~ 0 ;° S RG - 1 f B ' 3 ma "~ ~*.e.. a logical addre !, 
00000001 ,s used to manage information of a card number ",234 5678 
9012 3456 , and a management number -00000010" is used to manage 
informatron of a card number ',234 5612 3456 7690". ,„ 0 , er words 

the card number "1234 5678 9012 ^ , 

° yu12 3456 are stored and manaaed in ^ 

"«IZr """"" »™>°— » » - M» 

The management number and th<* r, r w „ u 
-morv chip of the card (S150) FIG 7™ * 
memory structure o, the card Re ! 30 eXamP ' e ° f 3 

including a card n„„K " 9 '° F ' G ' 1C ' ^formation 

mg card number, a management number, and a valid term, which 
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are allocated to a card during issuance, is stored in the memory of the 
card. 

Card-approval-information of the card is stored in a predetermined 
region of memory (S160). In other words, card-approval-information 

5 and user attribute information are stored in a unit memory section 
corresponding to the management number of the card. For example, 
when a card to be issued is a fifth card, a start address of the memory 
area is "00000000", and a size of a unit memory section in the memoiy 
area is 2 bits, a management number of the card is "5". That is, a 

10 logical number of the card is "5". When necessary values are applied to 
Formula (1), an actual address of the logical address "5" is calculated like 
Formula (2). 

Actual address of logical address "5" = 0 + 2(5-1) = 8 ...(2) 

15 

That is, the actual address of the logical address u 5" is "8". 
Accordingly, the card-approval-information is stored in a 2-bit region 
starting from a point corresponding to the actual address "8". The 
card-approval-information is commonly configured according to rules 

20 agreed with by all card companies. For example, rules can be made 
that a first bit indicates validity/non-validity of a card, a second bit 
indicates a user attribute, the card is recognized to be valid when the first 
bit is "1" and invalid when the first bit is "0", and a card user is recognized 
to be a normal adult when the second bit is "1" and a student when the 

25 second bit is "0". According to these rules, card-approval-information 
can be configured, as shown in FIG. 1D. When the 
card-approval-information shown in FIG. 1D is interpreted according to 
the rules, the card is valid and a user of the card is a student. The user 
attribute needs to be stored in the card-approval-information because an 

30 adult fare and a student fare are different in a transport fare (for example, 
a bus fare or a subway fare) system. 
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After card-approval-information of all cards to be initially issued or 
reissued is stored, a card-approval-information download message is 
generated (S170) and transmitted to a predetermined system and 
terminal apparatuses which require the card-approval-information (S180). 
5 As shown in FIG. 1E, the card-approval-information download message 
may include a start address of a memory area having a predetermined 
size and including a plurality of unit memory sections and data stored in 
the memory area. Alternatively, as shown in FIG. 1F, the 
card-approval-information download message may include a start 
10 address of a memory area having a predetermined size and including a 
plurality of unit memory sections, a difference value between the start 
address and a logical address of a unit memory section in which data is 
changed, and the changed data. Preferably, the 

card-approval-information download message having a format shown in 
15 FIG. 1E is used for initial data transmission, and the 
card-approval-information download message having a format shown in 
FIG. 1F is used when there is a change in stored data. 

FIG. 2 is a block diagram of a credit-card system according to an 
embodiment of the present invention. Referring to FIG. 2, the 
20 credit-card system includes a card terminal 100, an aggregate computer 
200, and a central computer 300. 

The central computer 300 is connected to a server system of a 
card company 400 through Internet or a private line. The central 
computer 300 receives poor credit information (i.e., black list (BL) data) 
25 and card-approval-information having a memory address from the server 
system and stores and manages them in a separate storing place. The 
poor credit information indicates BL data including card numbers of cards 
having a poor credit history. The card-approval-information having the 
memory address has been described above with reference to FIGS. 1 
30 through 1F. 
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The aggregate computer 200 is connected to the central computer 
300 and the card terminal 100 through the Internet or the private line. 
The aggregate computer 200 receives the BL data and the 
card-approval-information having the memory address from the central 
5 computer 300, stores and manages them in a separate storing place, and 
transmits them to the card terminal 100. In addition, the aggregate 
computer 200 transmits the result of processing performed by the card 
terminal 100 to the central computer 300. 

The card terminal 100 receives the BL data and the 
10 card-approval-information having the memory address from the 
aggregate computer 200 and stores and manages them in a separate 
storing place. In addition, the card terminal 100 generates radio waves, 
communicates with a radio frequency (RF) card 10 approaching within a 
predetermined distance therefrom using the radio waves, and determines 
15 validity/non-validity of the RF card 10 based on the BL data, the 
card-approval-information, and card information obtained via the 
communication with the RF card 10. 

The aggregate computer 200 may be omitted according to an 
ambient environment such as a scale of the entire credit-card system. 
20 FIG. 3 is a block diagram of the card terminal 100 of the 

credit-card system according to the embodiment of the present invention. 
Referring to FIG. 3, the card terminal 100 includes a radio wave 
generator 110, a card information reader 120, a memory manager 130, a 
first memory 140, a second memory 150, a communication module 160, 
25 and a card approver 170. 

The communication module 160 performs data communication 
with an apparatus (for example, the aggregate computer 200 or the 
central computer 300) connected to the card terminal 100. The first 
memory 140 stores and manages card-approval-information having a 
30 memory address. The card-approval-information is transmitted from the 
aggregate computer 200 or the central computer 300 through the 
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communication module 160. In order to store and manage the 
card-approval-information, the first memory 140 divides an entire 
memory area into unit memory sections having a predetermined size and 
allocates a logical address to each unit memory section. 
5 The radio wave generator 110 generates and radiates radio waves 

outside and communicates with at least one card approaching within a 
predetermined distance therefrom using the radio waves. In addition, 
the radio wave generator 110 transmits information, which is received 
from the card as the result of communication, to the card information 
10 reader 120. 

The card information reader 120 decodes the information received 
from the card through the radio wave generator 110 to read card 
information including a card number and a management number which 
are allocated during issuance, a valid term, and a usable amount and 
15 then transmits at least one of the card number and the management 
number to the memory manager 130. The reason at least one of the 
card number and the management number is transmitted to the memory 
manager 130 is because a certain type of card (for example, a Kookmin 
credit card) does not have a management number. 
20 The memory manager 130 manages data stored in the first 

memory 140 and data stored in the second memory 150 according to 
information received from the aggregate computer 200 or the central 
computer 300 through the communication module 160. For example, 
when the card-approval-information having the memory address is 
25 received through the communication module 160, the memory manager 
130 calculates a logical address of the first memory 140 in which the 
card-approval-information is to be stored by applying the start address of 
the memory area in a card company, the start address being included in 
the card-approval-information, to a predetermined algorithm and then 
30 stores the card-approval-information in a region corresponding to the 
logical address in the first memory 140. When the BL data is received 
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through the communication module 160, the memory manager 130 
stores the BL data in the second memory 150. 

in addition, the memory manager 130 extracts 
card-approval-information and BL data, which correspond to card 
5 information read by the information reader 120, from the first memory 
140 and the second memory 150. For example, when a management 
number is received from the card information reader 120, the memory 
manager 130 calculates a logical address of the first memory 140 by 
applying the management number to a predetermined algorithm, extracts 
10 card-approval-information stored in a region corresponding to the logical 
address from the first memory 140, and transmits the extracted 
card-approval-information to the card approver 170. When only a card 
number is received from the card information reader 120, the memory 
manager 130 determines whether the card number is included in the BL 
15 data stored in the second memory 150 and transmits the result of the 
determination to the card approver 170. 

The card approver 170 determines whether a card approaching 
the radio wave generator 110 is valid based on card-approval-information 
and BL data, which are extracted by the memory manager 130, and card 
20 information read by the card information reader 120. More specifically, 
the card approver 170 primarily determines whether the card is valid 
based on the card-approval-information and the BL data received from 
the memory manager 130 and secondarily determines whether the card 
is valid based on a valid term and a usable amount received from the 
25 card information reader 120. In other words, even if it is determined that 
the card is valid based on information received from the memory 
manager 130, when the valid term is expired or when the usable amount 
is less than the amount of settlement, the card is determined as invalid. 

FIGS. 4 through 7 are flowcharts showing an operation of a card 
30 terminal according to the embodiment of the present invention. 
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Referring to FIG. 4, the card terminal manages 
.card-approval-information received from a card company (S200) and 
determines whether to approve a card approaching within a 
predetermined distance therefrom (S300). 
5 FIG. 5 shows a flowchart of step S200. Referring to FIG. 5, when 

the card terminal receives card-approval-information from a card 
company (S210), the card terminal determines a type of the 
card-approval-information and when the type of the 
card-approval-information is BL data, stores or updates the BL data in a 
10 BL data storage area (S220). When the type of the 
card-approval-information is comprehensive credit information including 
both valid and invalid card information, the card terminal stores or 
updates the comprehensive credit information in a comprehensive credit 
information storage area (S23Q). The comprehensive credit information 
15 corresponds to card-approval-information having a memory address. 

FIG. 6 is a flowchart of step S230 shown in FIG. 5. Referring to 
FIG. 6, a start address of a card company memory is extracted from the 
comprehensive credit information received from the card company 
(S231). Next, a card terminal memory address, in which the 
20 comprehensive credit information is to be stored in the card terminal, is 
calculated using the start address of the card company memory (S232). 
Preferably, the card terminal memory address is calculated using a 
formula differently predetermined depending on the memory 
characteristics of the card terminal. Thereafter, the comprehensive credit 
25 information is stored in the card terminal memory address (S233). 

FIG. 7 shows a procedure in which the card terminal determines 
whether to approve the card in step S300. Referring to FIG. 7, when 
card information is read from the card approaching the card terminal 
(S310), it is determined whether a management number is included in 
30 the card information .(S320). The management number indicates a 
memory address in which the card-approval-information is stored. If it is 
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